home *** CD-ROM | disk | FTP | other *** search
/ Hyper Stacks 1994 May / Hyper Stacks (Pacific HiTech)(1994)[Mac].iso / MacTools / TC Prog Guide / app ƒ / app.h < prev    next >
Encoding:
C/C++ Source or Header  |  1991-01-30  |  4.2 KB  |  115 lines  |  [TEXT/KAHL]
  1. /*
  2. *    FILE:        app.h
  3. *    AUTHOR:        R. Gonzalez
  4. *    CREATED:    August 25, 1990
  5. *
  6. *    Defines generic application class.  An application may be derived
  7. *    from any of the derived abstract application classes, such as the
  8. *    Command_App (command-line app.) class.  To change the "look" of
  9. *    the application the programmer need only change the parent of the
  10. *    new application to a different abstract application class, such as
  11. *    Menu_App.  Also, unless the TC-only 'inherited' keyword is used to
  12. *    call the parent class, explicit calls to the parent class must be
  13. *    changed as well.  To make this easier we've defined a macro like:
  14. *    
  15. *        # define    PARENT_CLASS    Command_App
  16. *
  17. *    in the header for each of the derived abstract classes (Command_App,
  18. *    Menu_App, etc.).  Use PARENT_CLASS to refer to the parent class.
  19. *    Then you can change the look of your application simply by #includ-
  20. *    ing the appropriate header file!  An example is discussed below.
  21. *
  22. *    Limitations:  The user interface of the programmer's application
  23. *    must rely upon a set of commands.  Other than this, the only way
  24. *    the application may communicate with the user is via character
  25. *    strings passed in query() and respond() messages.  No graphics
  26. *    are provided for, in keeping with the lowest-common-denominator
  27. *    user interface.
  28. *
  29. **********************************************************************
  30. *
  31. *    Here's how to write your own application class My_App.  Create
  32. *    the header myapp.h and #include the desired parent application
  33. *    class header (comapp.h, menapp.h, or macapp.h).  Define your
  34. *    class like:
  35. *
  36. *        struct    My_App:PARENT_CLASS
  37. *        {
  38. *                .
  39. *                .
  40. *        };
  41. *
  42. *    using any new instance variables you like, and overriding init
  43. *    and destroy to perform your own initializations.
  44. *
  45. *    Next, create the source file myapp.c.  Here you should define
  46. *    static functions for each command your application will handle.
  47. *    Each of these should return a boolean and take a single argument:
  48. *    a pointer to an object of type My_App.  This parameter must
  49. *    be used to access your application's instance variables as well
  50. *    as the query() and respond() functions.  For example:
  51. *
  52. *        static boolean    open(My_App* app_ptr)
  53. *        {
  54. *            char    filename[80];
  55. *
  56. *            app_ptr->query("Enter file name: ",filename);
  57. *            app_ptr->file = fopen(filename,"r");
  58. *                .
  59. *                .
  60. *        }
  61. *    
  62. *    (See the note below for why static functions are used instead
  63. *    of member functions.)  In your init method you should first call
  64. *    PARENT_CLASS::init(), then send log_command messages to the menu
  65. *    instance variable (inherited) to associate a name and function
  66. *    pointer to each command your application handles.  The parent
  67. *    class will automatically call the appropriate static function
  68. *    when the corresponding command is selected by the user.
  69. *
  70. **********************************************************************
  71. *
  72. *    NOTE:  This version logs the command name and number, as well as
  73. *    a pointer to the function itself, into the menu object.  The
  74. *    current implementation of TC (as with early versions of C++) does
  75. *    not support taking the address of a method.  Therefore for now
  76. *    we are using static functions to implement this.  In the future
  77. *    it would be nice to use member functions instead, so that they
  78. *    may easily access instance variables of the derived application
  79. *    class.  (The "app_ptr->..." notation mentioned above will not be
  80. *    needed.)
  81. *    
  82. *    In our earlier version, the programmer did not log a pointer to
  83. *    the command function into the menu; rather, he/she had to write a
  84. *    do_command() method for the new application which contained a case
  85. *    statement selecting the function associated with the command
  86. *    chosen.  This approach allowed the command functions to be member
  87. *    functions, but was otherwise more prone to errors.
  88. */
  89.  
  90. # ifndef    app_h
  91. # define    app_h
  92.  
  93. # include    "class.h"
  94.  
  95. struct    Menu;
  96.  
  97. /************************************************************************
  98. *    abstract application class
  99. ************************************************************************/
  100. struct    Generic_App:Generic_Class
  101. {
  102.     struct Menu            *menu;
  103.     boolean                done;
  104.     
  105.     boolean                init(void);
  106.     virtual    void        run(void);
  107.     virtual    void        query(char*,char[]);
  108.     virtual    void        respond(char*);
  109.     boolean                destroy(void);
  110. };
  111.  
  112. # include    "menu.h"
  113.  
  114. # endif
  115.